Public Key Infrastructure (PKI) provides an infrastructure for managing public key used for authenticating messages using public key cryptography. PKI generally allows for management of asymmetric cryptography keys, wherein different keys are used for encryption and decryption. In particular, a pair of keys, one public and one private, is generated for each user. When information is encrypted with the public key, it can be decrypted only with the corresponding asymmetric private key. Accordingly, for example, when a sender of a message uses the public key of a recipient to encrypt the message, the contents of the message can only be read after being decrypted with the recipient's private key. Conversely, the sender may digitally sign the message with the sender's associated private key, wherein the authenticity of the digitally signed message can be verified using the sender's public key. Hence, when the recipient successfully uses the sender's public key to verify information digitally signed with the sender's private key, the recipient can be certain of the sender and the integrity of the information.
To ensure the trustworthiness of public/private keys, certificate authorities (CA) issue digital key certificates that are digitally signed by the CA to guarantee that an individual issued a digital certificate is, in fact, who the individual claims to be. Each digital certificate includes, among other information, the name of the certificate holder, a serial number, an expiration date, the certificate holder's public key, and the digital signature of the issuing CA. This information enables relying parties receiving information signed with the private key associated with the digital certificate to verify the authenticity and integrity of the information.
A relying party is an entity that relies on the validity of a certificate holder's digital certificate to perform cryptographically operations with the certificate holder. Such cryptographic operations may include, for example, encryption, decryption, and source authentication. A certificate holder is an entity to which a digital certificate is issued. One type of certificate that may be issued to a certificate holder is an identify certificate, which binds a public key contained in the certificate to the certificate holder's identity also contained in the certificate. As is known in the art, for any public key there is an associated private key. The certificate holder is typically the only entity to have access to the private key associated with the public key contained in the certificate. This private key is also said to be associated with the certificate. A digital certificate issued to an entity that is no longer trustworthy, or a certificate for which the associated private key may have been used in an unauthorized manner or may have been exposed outside the required crypto-boundary, is known as a compromised digital certificate or a compromised certificate.
In the PKI certificate life cycle, a digital certificate may become invalid when either the certificate expires on the expiration date noted in the digital certificate or if it is revoked prior to its expiration date. For example, if a certificate holder ceases to be trusted or if the certificate holder's private key is compromised, the digital certificate associated with the holder or the holder's public key may be revoked. To revoke the digital certificate, a certificate revocation request needs to be submitted to the issuing CA. As part of processing the revocation request, the issuing CA authenticates the revocation request, and if the authentication is successful, the issuing CA revokes the digital certificate and publishes the revoked certificate in a Certificate Revocation List (CRL). The CRL is also herein referred to as a Certificate Status List or a Certificate Status Database. A CRL may include one or more of a list of certificate identifiers, an associated revocation status, a revocation timestamp, a revocation reason, as well as other information. Any portion of the contents of the CRL is herein referred to as certificate status information. The CRL is signed by the CRL issuer, so that the CRL may be verified cryptographically. The CRL may be as simple as a list of certificate identifiers and a signature. The certificate identifiers may include certificate serial numbers, distinguished names, public key identifies (such as a hash of the public key), and/or any other information associated with the certificate holder that can be used to uniquely identify the revoked certificate.
If the entity submitting the revocation request belongs to the same domain (local domain) as the certificate holder's issuing CA, the certificate revocation process could be instantaneous. However, when the entity submitting the revocation request belongs to a different domain (remote domain or relying party domain) than the certificate holder's issuing CA, there may be difficulties in submitting and/or authenticating the revocation request. In addition, in an adhoc network where there may be no connectivity with the PKI, the revocation request submitted by an adhoc node may not reach the issuing CA in a timely manner.
Upon receiving information cryptographically processed using a private key associated with a digital certificate, a relying party can use the digital certificate to validate the authenticity and integrity of the information. Further, the relying party may choose to validate the certificate by, among other things, obtaining the appropriate CRL to determine if the certificate being validated is listed in the CRL. The issuer of a CRL is called a CRL issuer. Normally the CRL issuer is the same CA which issued the certificate being revoked. It is also possible for the CA to authorize a third party to be an external CRL issuer. In both cases, the same policies may be adhered to and similar mechanisms used to issue the CRL.
When the revocation request policy requires that the issuing CA authenticates each revocation request, the digital certificate being revoked may remain valid for some time while the request is being processed. In this case, all transactions associated with these digital certificates could potentially be untrustworthy while the revocation process is being processed. If a compromised digital certificate is validated while the revocation is being processed, the issuing CA may be subjected to liabilities based on agreements signed with relying parties or other CAs, where there is typically a provision that the issuing CA will promptly update the CRL.
In order to prevent the relying party from accepting the digital certificate as valid while the issuing CA is processing an associated revocation request, the issuing CA may temporarily suspend the digital certificate while the authentication process is being completed. When the relying party receives information secured with a private key associated with a temporarily suspended digital certificate, the relying party will be unable to validate the suspended digital certificate. It should be noted that by temporarily suspending or revoking the digital certificate during the revocation request process, the issuing CA and/or subject of the certificate could be susceptible to denial of service attacks.
These problems can be exacerbated when the entity submitting the revocation request is in a different domain than the issuing CA. For example, if there is a conflict between policies implemented in the domain of the entity submitting the revocation request and the domain of the certificate holder's issuing CA regarding a revocation request, entities in the requestor's domain and the certificate holder's domain may need some time to determine how best to handle the revocation request. Consider a case where the revocation request cannot be processed immediately because the certificate holder violated a policy of the relying party domain. If the certificate holder operated within the constraints of operating policies of the certificate holder's domain, an entity in the certificate holder's domain may not agree that the certificate should be revoked. During the time required to resolve the disagreement, if the issuing CA is configured to temporarily suspend/revoke the certificate, the issuing domain could be susceptible to denial of service attacks. If, on the other hand, the issuing CA is configured to not temporarily suspend/revoke the certificate, the relying party domain may be unable to invalidate the digital certificate associated with the revocation request submitted by the relying party's domain.
Therefore, there is a need for a validation method for a relying party domain to verify the status of a digital certificate against a certificate status list managed by the relying party domain independent of the revocation status managed by the certificate holder's domain CA. The certificate status list managed by the relying party domain is also referred to as a private certificate status list and the certificate status list managed by the certificate holder's domain is also referred to as a public certificate status list.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.